Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(qt): Governance Tab should respect selected units and settings #6403

Merged
merged 1 commit into from
Nov 20, 2024

Conversation

UdjinM6
Copy link

@UdjinM6 UdjinM6 commented Nov 18, 2024

Issue being fixed or feature implemented

Governance Tab ignores selected units and settings atm. Let's fix this.

Display settings:
Screenshot 2024-11-19 at 00 49 35

develop:
Screenshot 2024-11-19 at 00 47 35
Screenshot 2024-11-19 at 00 48 02

this PR:

Screenshot 2024-11-19 at 00 49 04 Screenshot 2024-11-19 at 00 49 17

What was done?

How Has This Been Tested?

Breaking Changes

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation
  • I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

@UdjinM6 UdjinM6 added this to the 22.1 milestone Nov 18, 2024
Copy link
Member

@PastaPastaPasta PastaPastaPasta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 90923ae

case Column::PAYMENT_AMOUNT:
return proposal->paymentAmount();
case Column::PAYMENT_AMOUNT: {
return BitcoinUnits::floorWithUnit(m_display_unit, proposal->paymentAmount() * COIN, false,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, I just noticed that proposal->paymentAmount() returns float here.

str_amounts is assigned as string ValueFromAmount(payment.nAmount)) which doesn't lose precision, but conversion back through float and multiplying to COIN can potentionallly add a strange 0.00000002 at the end, I think.

Is it possible to avoid conversion to float here?

        if (UniValue amountValue = find_value(prop_data, "payment_amount"); amountValue.isNum()) {
            m_paymentAmount = amountValue.get_real(); // <----- here
        }

Copy link
Author

@UdjinM6 UdjinM6 Nov 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! We should be using double here. Will fix in a follow-up PR.

EDIT: #6404

Copy link
Collaborator

@knst knst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 90923ae

@PastaPastaPasta PastaPastaPasta merged commit 3c80dfc into dashpay:develop Nov 20, 2024
34 checks passed
PastaPastaPasta added a commit that referenced this pull request Nov 21, 2024
…vernance Tab

c48efda fix(qt): avoid potential precision loss in amounts on Governance Tab (UdjinM6)

Pull request description:

  ## Issue being fixed or feature implemented
  #6403 (comment)

  ## What was done?

  ## How Has This Been Tested?

  ## Breaking Changes

  ## Checklist:
  - [ ] I have performed a self-review of my own code
  - [ ] I have commented my code, particularly in hard-to-understand areas
  - [ ] I have added or updated relevant unit/integration/functional/e2e tests
  - [ ] I have made corresponding changes to the documentation
  - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_

ACKs for top commit:
  knst:
    utACK c48efda
  PastaPastaPasta:
    utACK c48efda

Tree-SHA512: 705bc154e10150e32e3ff04d4a90de14e29ffd195cc9f94a753dd1b4588f2730d6526cd66d851005b956e0d074d39250d142baa946bea8df95dbc92718931762
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants